Sample handling robots of various configurations are known in the biotechnology industry. A common feature of such systems is the use of a robotic or other motion control device to either move a fluid aspirating/-dispensing syringe (herein generally referred to as a sampling probe) about a deck of vessels or other deck components like wash stations, reagent troughs, injection valves, etc., or to move the vessels and/or other deck components relative to a stationary sampling probe. Among the more sophisticated systems, plural sampling probes are ganged together for common movement by a sample handler. These systems generally fall into two different categories.
In a first category, the sampling probes are attached to a single holding bracket affixed to a transport member, commonly referred to as a gantry. All of the sampling probes travel together as a unit. While such systems are easy to design, build and implement, a disadvantage is that all of the ganged probes must travel in the X, Y and Z axes together. Even if only one of the probes needs to draw a sample from a vessel at a sampling station, for example, all of the probes will be immersed in their respective vessels at a sampling station. This increases the risk of sample and/or probe contamination and carryover.
In a second category, the systems are designed to allow independent Z axis motion for each sampling probe. That is, each probe can travel toward and away from the deck independently of the other probes. This allows one or more of the probes to be immersed in their respective vessels while the remainder remain suspended above their respective vessels at a sampling station.
In both cases, the probes must be simultaneously positioned in relation to the various work stations, such as a wash station, sampling station, injection station, etc. In the various automated sample transport implementations known in the art, the transport functionality is completely deterministic both spatially and temporally.
In addition, the transport functionality is either schedule or operation-table driven. Before execution, the system control software would be made aware of the number and types of transportable devices, the number and types of objects on which the devices must operate, and the specific workflow for each object. The system also would be instructed, or calculates via a deterministic set of algorithms, where each transportable device must be within the workflow relative to the others (temporally and spatially) and the exact sequence of operations from start to finish.
This paradigm works sufficiently well when overall processing throughput is not a concern and also when there are only a couple transportable devices each of which remains dedicated to a given operation for its duration. In typical cases, the system assumes the workflow of one of the objects and sees it through to the end before attending to the workflow of another object or a new workflow for the same object. All remaining objects are processed in sequence.
The problem becomes more complex when overall throughput is of concern or when several transportable devices must be administered during execution, especially when individual unit operation time frames are not balanced throughout the workflow.
The prior art systems also are not able to handle failure situations very well. For example, if a transportable device breaks down, the entire schedule must be recalculated and retransmitted to the system. Typically, major assumptions must be made to accommodate the modified labor deployment and in most cases, system operation gets suspended to wait for a user to reestablish the new schedule. In a worst case scenario, the system has to shut itself down and wait for repair.